Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/security/doc/clippings/920522-01

Internet Message Format | 1992-06-04 | 7.1 KB

From: [e-mail] (A PR problem for DEMAX)
Newsgroups: alt.security
Subject: diary of a security incident
Keywords: security, security incidents
Message-ID: <[e-mail]>
Date: 22 May 92 19:46:00 GMT
Organization: University of Arizona

Cross post to various places - sorry if you have seen it already.
    comp.os.vms, alt.security, DECUS bbs (DECUServe) and others

Wednesday, May 20, 1992 a VMS V5.4-1 system was discovered to have been soundly
and skillfully hacked.  While this particular attack was specific to this
version of VMS, it is certainly possible to do on other versions as well as
other operating systems.  In addition, the case presents many classic lessons
for the security management of all systems and networks.

At about 13:00, a user reported that they had made a typo at the PASSWORD:
prompt of a VMS V5.4-1 system and discovered that 5 characters (which were not
their password) would allow them access to their account.  Upon subsequent
investigation (which took place after the system was actually lost to an
attacker), it was discovered that any 5 alphanumeric characters (not special
characters, interestingly enough) OR an account's real password would allow
access to any account on the system.

Word or this problem leaked into the user community (this system has about 500
accounts) at large very quickly and at 18:30 someone dialed into the system and
took control of it by (in quick succession) turning off security auditing,
changing all key passwords (SYSTEM, the System Manager's and that of the System
Administrator) and stopping the processes of the System Manager and the System
Administrator.  After a quick system halt, and a conversational boot, control of
the system was regained by carefully making cleanup changes to the User
Authorization File and installing defensive measures.

Our preliminary investigation reveals a skillfully patched version of LOGINOUT
which escapes the view of the casual observer - the patch was only detected by
comparing the checksum of the suspect LOGINOUT to that of one obtained from
operating system distribution media.  Subsequent investigation reveals that this
system had been experiencing security problems (which were not cleaned up
properly) for quite some time (over a year).  In a recent episode (some months
ago), an unauthorized privileged account was discovered.  The System
Administrator chose to remove the privileges from the account and leave it on
the system without taking any other actions.  During this most recent episode,
this same account was - once again - discovered to have unauthorized privileges.
Our conclusion is that this normally unprivileged user had the ability to
obtain unauthorized privileges at will and knew exactly how to make use of them
to patch LOGINOUT.  At this writing, it has not been able determined how
privileges were obtained or if, in fact, if this particular account was
responsible for the patched LOGINOUT.  It is, however,  evident that these
conclusions are highly probable.

Here are some important CHECKSUMS to consider.  They were taken from images on a
CDROM release of VMS V5.4-1.  Just because yours might match these, don't think
that you are safe from an attack on them.  The "native" VMS CHECKSUM utility IS
*NOT* robust for detecting all possible changes to a file - especially changes
to an image.  Consider the checksums produced by the "native" VMS checksum
utility to be a "quick indicator" that there is a problem.  It is NOT clear that
the LOGINOUT images is the only one that was affected in this incident - these
are just the ones that we looked at in the heat of trying to find out what
happened.  First we examined the CHECKSUM utility itself to gain confidence that
this tool was uncompromised, and then we examined the LOGINOUT image as the
likely cause of the problem.  Note, the following checksums are from images on a
CDROM release of VMS V5.4-1 - NOT the compromised utilities.

$ checksum loginout.exe/image
file $90$DKB400:[VMS054]LOGINOUT.EXE;1
image section %D'1' checksum is %X'64040716'
image section %D'2' checksum is %X'30FAA60E'
image section %D'3' checksum is %X'50D98C63'
image section %D'4' checksum is %X'D940C862'
image section %D'5' checksum is %X'DBCF1E90'
image section %D'6' checksum is %X'F25B5AEB'
image section %D'7' checksum is %X'000F2815'
image header checksum is %X'13001A2D'
checksum of all image sections is %X'F4FC8977'

$ checksum checksum.exe/image
file $90$DKB400:[VMS054]CHECKSUM.EXE;1
image section %D'1' checksum is %X'444E7A57'
image section %D'3' checksum is %X'E0E223A0'
image section %D'4' checksum is %X'6B86477E'
image section %D'5' checksum is %X'42080D22'
image header checksum is %X'6EF70B31'
checksum of all image sections is %X'8D2213AB'

The *only way* to BE SURE that you have "unpatched" images it to DIFF them with
known good ones (i.e.: from a known good distribution) or to use a "checksummer"
that employs an algorithm that has cryptographic strength.  It is also helpful
to have a "change detection tool" that knows enough about the structure of the
files that you are checking to ensure that subtle changes have not been made to
them.  A product that does both of these things (and is worthy of your
consideration) is one from DEC called DECdetect.  The "native" VMS CHECKSUM
utility is not robust enough to rely upon for this work, although it DID find
this particular problem.

At this writing, the actual happenings with this incident are still not well
understood, but it IS clear that the basic rules of good system/network security
management would have worked wonders.  Take a close look at your systems -
especially accounts with privs and "strange" loginout behavior.   An important
lesson:   Do not let obvious security-related problems go unattended.  If you
discover a security problem (i.e.: the appearance of unauthorized privileges on
an account or the obvious misbehavior of a key system program such as LOGINOUT)
- act *immediately* to regain control and trust of the system.  Security
assessment tools used under the guidance of an enforced security policy and the
discipline to institute vigorous cleanup measures after the discovery of a
problem are absolute musts.

I presented a review of the available security assessment tools for VMS in an
article in ISPNews (Vol 3, Issue 2 - March/April 1992) and I wrote a review of
the DECdetect tool in the March 2, 1992 issue of Digital News.  You can contact
ISPNews by FAX at [phone] and DECdetect product
information can be obtained by FAX from DEC's Peter Troxell at [phone].
Recently, a detailed comparison of VMS security assessment tools was posted to
USENET news group comp.os.vms by NASA System Administrator Greg Blumers.  Copies
of Greg's review can be obtained by sending mail to
[e-mail].  If you do not have access to the Internet, please
feel free to FAX me a request for a copy of Greg's work at [phone].  I am
writing a complete chronology of this episode.  If you'd like a copy of the
finished work, send me mail (paper or otherwise).

Ray Kaplan
P.O. Box 42650
Tucson, AZ  85733
Internet: [e-mail]
BITNET: kaplan@arizvms
FAX [phone]


RayK 8-)